Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci: Check PR title instead of commits for conventional format #264

Merged
merged 1 commit into from
Apr 13, 2022

Conversation

ethan-lowman-dd
Copy link
Contributor

Release Notes: PR titles must now use Conventional Commit format

Types of changes:

  • [ ] Bug fix (non-breaking change which fixes an issue)
  • [ ] New feature (non-breaking change which adds functionality)
  • [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of the changes being introduced by the pull request:
One of the effects of #234 is that we have to format every commit message using the Conventional Commit format, even though we squash merge PRs, and that commit history is lost. Since the PR title (or in some cases a single commit message) becomes the squashed commit message, that is the place we should check for proper formatting. I swapped in a GitHub action that performs this check.

Please verify and check that the pull request fulfills the following requirements:

  • Tests have been added for the bug fix or new feature
  • Docs have been added for the bug fix or new feature

rdimitrov
rdimitrov previously approved these changes Apr 10, 2022
Copy link
Contributor

@rdimitrov rdimitrov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the action we are currently using has support too for checking only the PR title via:

pull_request:
  conventional: true

, but I haven't tried it yet (ref. https://commitsar.aevea.ee/configuration/config-file/)

Anyway, I find the action you suggested to be better and it's also more widely adopted, so I think it make sense for us to switch to it 👍

A few nits:

  • Not sure if it should be of a concern, but I do like that the one we have doesn't rely on having the GITHUB_TOKEN exposed.
  • Should we configure the set of allowed change types (here) to be in line with the changelog groups goreleaser builds (here)?

@ethan-lowman-dd ethan-lowman-dd force-pushed the ethan.lowman/check-pr-title branch from 1a13d0c to 1260893 Compare April 12, 2022 17:38
@ethan-lowman-dd
Copy link
Contributor Author

Not sure if it should be of a concern, but I do like that the one we have doesn't rely on having the GITHUB_TOKEN exposed.

By default the token has only read permissions, unless there's a different default setting a the repo or org level. I don't have the permissions to verify this.

Should we configure the set of allowed change types (here) to be in line with the changelog groups goreleaser builds (here)?

In that file, it doesn't look like we're restricting the set of allowed change types, just configuring their order in the changelog.

@rdimitrov rdimitrov self-requested a review April 13, 2022 07:48
Copy link
Contributor

@rdimitrov rdimitrov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we configure the set of allowed change types (here) to be in line with the changelog groups goreleaser builds (here)?

In that file, it doesn't look like we're restricting the set of allowed change types, just configuring their order in the changelog.

The order is set in the goreleaser config file whereas in the first one I think we can specify which types are allowed -

        with:
          # Configure which types are allowed.
          # Default: https://github.com/commitizen/conventional-commit-types
          types: |
            fix
            feat

Currently, the changelog will have breaking, fix and feat and everything else will go to others. So my thought was do we want to have separate ones for things like docs, ci, etc and on other side enforce the types we want to allow?

@ethan-lowman-dd
Copy link
Contributor Author

@rdimitrov Personally, I think we should leave it flexible, and then if/when well-defined categories emerge, we can formalize it.

Copy link
Contributor

@hosseinsia hosseinsia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ethan-lowman-dd ethan-lowman-dd merged commit 5b81b7e into master Apr 13, 2022
@ethan-lowman-dd ethan-lowman-dd deleted the ethan.lowman/check-pr-title branch April 13, 2022 19:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants